Skip to main content

Reply to this post | See parent post | Go Back
View Post [edit]

Poster: brewster Date: Nov 27, 2002 11:42am
Forum: movies Subject: Re: Re: Techy volunteer needed: setup linux tools for conversion

thank you for the offer. you are on!

below at the >> are some answers to your questions.

Poster: Doug Merritt Date: November 27, 2002 05:12:56pm
Forum: movies Subject: Re: Techy volunteer needed: setup linux tools for conversion
Coincidentally, I just started looking into this
for reasons of personal interest,
so I hereby volunteer to do some initial
investigation, and possibly more than that.

I understand the technical background on the
subject, but I haven't fiddled much with
freely-available mpeg tools on Linux yet,
so I'm not sure how much total work will be
involved, and hence can't give a firm commitment
to a final deliverable (especially if I become
employed soon :-)

>> sounds good.

Is there more on your requirements list than
what you already said, or is it simply a
desire to provide more formats?

>> we want to provide VCD and Mpeg-4 so that people
>>will lower bandwidth connections can see the
>>movies without the heavy weight download of
>>an mpeg-2.

For instance, is use of commercial software
desirable or undesirable? (I favor open source,
and preferably free, when it works to do so,
but it doesn't always work that way.)

>> we like to run on a cluster, so command line
>>oriented, and not tied to one cpu are
>>highly desirable.

Do you want quality guarantees or just best
effort? If a package introduces certain
artifacts by re-sampling audio or images
to a different frame-rate/sampling rate
(a known can of worms), is that acceptable
or unacceptable?

>> degradation is acceptable.

Is it desirable to retain the exact original
bits whenever possible, e.g. so that round-trip
conversion is at least theoretically approximately
possible, or is that unimportant, or is
degradation (e.g. for sake of speed) actually
desirable, or is audio/image "improvement"
desirable? (E.g. from scan line interpolation,
motion tracking and interpolation, DCT artifact
pre-compensation, etc etc etc)

>> we should do what we can as easily as we can.
>> the mpeg-2 are our current reference standards
>> so people can go back to those.

I have my own opinions on all of this. If it
were me, I'd at least initially go for least
impact on the original data, trying neither to
degrade it nor to enhance it, but not worrying
too much either way for the first release, since
the converted format is not going to be a
precious archival version in itself.

In a second release it would be interesting to
aim at enhancement, for better user experience --
although the counter-argument is that such
should go into user viewing software. But what
if it can't be done in real time on user
equipment in the near term?

>> viewing should be realtime, encoding can be
>> way slow. we have lots and lots of machines
>> we can throw at this problem.

Counter-counter-argument: then it would soak
up too much server cpu. (The argument doesn't
end there, either, of course.)

I'm not sure of the right answer, but I do
think that e.g. early Edison Archive films, for
instance, are in fact very badly in need of all
the enhancement they can get, for the sake
of the user experience, but not in the archived
bits, which need to be preserved as exactly
as possible for posterity, future archaeology,
future better algorithms, etc.

Sorry to be long winded. It's a pet subject of
mine of long standing. :-)

>> pls send me an email at brewster at archive org
>> so I can set up an account for you.
>> -brewster